Skip to content

fix(server): the mode schema advertises the real board vocabulary - #52

Merged
Joshua-Gilbert merged 1 commit into
mainfrom
fix/mode-vocabulary-in-tool-schema
Aug 14, 2026
Merged

fix(server): the mode schema advertises the real board vocabulary#52
Joshua-Gilbert merged 1 commit into
mainfrom
fix/mode-vocabulary-in-tool-schema

Conversation

@Joshua-Gilbert

Copy link
Copy Markdown
Collaborator

Problem

create_task.mode and set_task_mode.mode described the board's modes as:

'code' | 'advanced' (adds MCP/Browser) | 'ask' (read-only) | 'orchestrator'

Two things wrong with that, both affecting every agent that reads the tool schema:

  • It lists four of eight. plan, review, refactor, and devsecops are all real board slugs with their own routing rules and safety profiles in modes.ts, and none of them appear. A caller has no way to discover from the schema that it can ask for a review.
  • The four it does list are the stalest four. On Bob 2.0, code/advanced/orchestrator are not modes Bob has — toBob2Mode remaps all three to agent at dispatch. The schema advertised the one subset that no longer means what it says.

This is also the copy that ships to the marketplace: lhm.plugin.json carries these strings verbatim, so the listing published the same wrong schema.

Change

Both descriptions now name all eight slugs, mark ask/plan/review read-only, and state the two facts a caller cannot infer from a slug:

  • code/advanced/orchestrator run as agent on Bob 2.0
  • review/refactor/devsecops resolve only where the workspace carries .bob/custom_modes.yaml; elsewhere they downgrade with a warning (2.3.1) rather than hang

Routing itself still points at predict_mode rather than restating the keyword table, so there's one source of truth for how a modeless task gets routed.

No behavior change — these are description strings. The board's accepted vocabulary, MODE_PROFILES, and the router are untouched.

Verification

lhm.plugin.json's two strings were checked byte-for-byte against the built dist/server.js rather than eyeballed, so the marketplace copy cannot drift from the served schema:

create_task    MATCH built server
set_task_mode  MATCH built server
stale 4-mode list left in manifest: false
tools: 23 | manifest version: 2.3.1

Gate green: lint, format:check, 736/736.

The create_task and set_task_mode descriptions listed four modes —
code / advanced / ask / orchestrator — of the board's eight, so an agent reading
the schema had no way to learn it can ask for plan, review, refactor, or
devsecops. The half it did list is also the half Bob 2.0 no longer runs under
those names: code, advanced and orchestrator all remap to agent at dispatch.

List all eight, mark which are read-only, and state the two things a caller
cannot infer from the slug alone: that the 1.x trio runs as agent on 2.0, and
that review/refactor/devsecops resolve only where the workspace carries
.bob/custom_modes.yaml (elsewhere they now downgrade with a warning rather
than hang). Point at predict_mode for the routing preview instead of restating
the keyword table.

lhm.plugin.json carries the same two strings verbatim — it is the marketplace
listing's copy of this schema — so it moves with them.
@Joshua-Gilbert
Joshua-Gilbert merged commit 1e7e204 into main Aug 14, 2026
3 checks passed
@Joshua-Gilbert
Joshua-Gilbert deleted the fix/mode-vocabulary-in-tool-schema branch August 14, 2026 18:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant